Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

DICOM and DICOMweb

DICOM (Digital Imaging and Communications in Medicine) is the standard for medical images and the information around them. It is unusual among health standards in being both a file format and a network protocol, and in being close to universally implemented — essentially every imaging device made in the last thirty years speaks it.

The data model​

Four levels, in this order. Understanding this hierarchy resolves most confusion about imaging integration.

Patient
  └── Study        one imaging procedure — "CT chest, 2026-03-04"
        └── Series one acquisition within it — "axial, contrast phase"
              └── Instance   one image (or one structured report, or one
                             segmentation object)

Each level has a globally unique identifier (a UID — a dotted numeric OID). Study Instance UID, Series Instance UID and SOP Instance UID are the addresses of imaging data everywhere.

Attributes and tags. Metadata lives in tagged elements — (0010,0010) is Patient Name, (0008,0060) is Modality. Every image file carries the patient and study context inside it, which is why a stray DICOM file is a personal data incident and a stray JPEG usually is not.

Not just images. DICOM also carries Structured Reports (SR), radiotherapy objects, segmentations, presentation states, key object selections and waveforms. AI output is commonly returned as an SR or a segmentation object rather than a burned-in annotation.

The classic network services​

The DIMSE protocol, running over TCP, with services still ubiquitous in hospitals:

ServiceDoes
C-STORESend an instance to another node (a scanner pushing to PACS)
C-FINDQuery for studies matching criteria
C-MOVE / C-GETRetrieve instances
Modality Worklist (MWL)The scanner asks "who am I imaging next?" — fed from the RIS or EMR order
MPPSModality Performed Procedure Step — reports what actually happened
Storage CommitmentThe archive confirms it has taken custody, so the modality may delete

Application Entity Titles (AE Titles) identify nodes, and association negotiation establishes which transfer syntaxes both ends support. This is manual configuration on both sides — a fact worth knowing before promising a same-day integration.

Modality Worklist is the integration that matters most clinically. Without it, a radiographer types the patient's details at the console, and every typo becomes an unmatched study that a human has to reconcile later. Feeding MWL from the ordering system is the single highest-value imaging integration in most hospitals.

DICOMweb​

The RESTful re-expression of those services, over HTTPS, with JSON or XML metadata. This is what a modern architecture integrates against.

ServiceMethodPurpose
QIDO-RSGET /studies?PatientID=…Query for studies, series, instances
WADO-RSGET /studies/{uid}Retrieve instances, metadata, rendered frames
STOW-RSPOST /studiesStore instances
UPS-RSWorklist as a REST service

DICOMweb is what makes zero-footprint web viewers, cloud archives and imaging AI pipelines practical. It removes the AE Title configuration problem and lets imaging traffic pass through ordinary API gateways with ordinary OAuth authorisation.

Where imaging sits in the architecture​

   Ordering system (EMR / RIS)
        │  order  (HL7 v2 ORM / FHIR ServiceRequest)
        ▼
   ┌──────────────┐   MWL    ┌───────────┐
   │  RIS / order │─────────▶│ Modality  │  (CT, MRI, ultrasound, X-ray)
   │  broker      │          └─────┬─────┘
   └──────────────┘                │ C-STORE / STOW-RS
                                   ▼
                           ┌───────────────┐
                           │  PACS / VNA   │  long-term archive
                           └───┬───────┬───┘
                  WADO-RS      │       │   DICOMweb
                 ┌─────────────┘       └──────────────┐
                 ▼                                    ▼
        ┌────────────────┐                   ┌─────────────────┐
        │  Viewer        │                   │  AI inference   │
        │  (web / thick) │                   │  service        │
        └────────────────┘                   └────────┬────────┘
                                                      │ SR / segmentation
                                                      ▼
                                              back to PACS, and
                                              FHIR ImagingStudy /
                                              DiagnosticReport to the EMR

The FHIR boundary. Images stay in DICOM; the record that they exist goes to FHIR. ImagingStudy references the study by UID and endpoint; DiagnosticReport carries the radiologist's report; ServiceRequest carries the order. Do not attempt to put pixel data in FHIR resources.

VNA (Vendor Neutral Archive) is an architectural pattern, not a standard: a PACS-independent archive so that changing the viewer or the departmental system does not require migrating decades of images. In an ecosystem where PACS contracts turn over and images must be retained for decades, it is usually the right structure.

Design concerns​

ConcernNotes
VolumeA CT study is hundreds of megabytes; a digital pathology slide can be gigabytes. Storage growth is the dominant infrastructure cost in imaging.
RetentionLegally defined and long — often the lifetime of the patient. Tiered storage is not optional at scale.
Patient identityStudies arrive with locally typed demographics. Reconciliation against the client registry is a permanent operational function, not a migration task.
De-identificationRequires more than clearing the obvious tags: private tags, burned-in pixel annotations, and the UID structure itself can re-identify. Follow DICOM PS3.15 Annex E rather than improvising.
SecurityClassic DIMSE has weak native security; it is usually protected by network isolation. DICOMweb over TLS with token auth is the safer modern path.
CompressionLossy compression of diagnostic images is a clinical safety decision with regulatory implications, not a storage optimisation.

Open-source tooling​

ProjectRole
OrthancLightweight DICOM server with a strong REST and DICOMweb API; the usual starting point for small deployments and research
dcm4che / dcm4chee-arcFull-featured Java DICOM archive and toolkit, used in production at scale
OHIF ViewerWeb-based zero-footprint viewer, DICOMweb-native
pydicomPython library for reading and manipulating DICOM
DCMTKC++ toolkit and command-line utilities
Cornerstone.jsJavaScript imaging rendering library, underpins several viewers

All Tier 2. Managed DICOM stores are available from the major cloud providers — see AWS, Azure and GCP.

References​

Last updated on